Product documentation
HSO Service Management supports a range of business processes that combine Service Objects, Service Calls, Service Tasks, Service Contracts and financial integration. These processes often involve multiple functional areas, making it important to understand how configuration and operational decisions influence the complete service lifecycle.
This chapter provides a functional entry point for common business scenarios. It explains the underlying process, identifies the main business decisions and directs readers to the relevant detailed documentation.
Business scenario
A customer reports a malfunction or requests service for an existing Service Object. The service organization must register the request, determine the applicable service conditions, plan the required work and process the resulting costs and customer charges.
Process overview
The process starts by identifying the customer and Service Object and creating a Service Call with the appropriate Call Type. The applicable Service Level Definition determines the available service conditions and Project Integration. One or more Service Tasks are created using Event Codes that define the expected labor, materials and Service Operations. After scheduling and execution, the actual transactions are registered and realized. Once the Service Call is completed, eligible transactions can be invoiced through Project Management and Accounting.
Key considerations
The Call Type determines the service process, while the SLD and Project Integration establish the financial treatment. The Event Code defines the work to be performed, and the Service Task records its execution. These responsibilities should remain clearly separated when designing or troubleshooting the process.
Related documentation
See Service Objects, Service Calls, Service Tasks & Execution, Planning & Scheduling and Invoicing & Financial Integration.
Business scenario
A customer reports a defect that may be covered by a product or service warranty. The service organization must determine whether the warranty applies, handle the request according to the appropriate service conditions and ensure that covered work is processed correctly in financial reporting.
Warranty determination
Warranty information is maintained in relation to the Service Object and its applicable warranty conditions. When a Service Call is created, warranty handling can influence the Call Type and financial defaults. Depending on configuration, warranty assignment can involve a user prompt or automatic processing. The user should verify that the warranty applies to the reported issue and relevant service date.
Service handling and SLA
Warranty does not eliminate the need for normal service processing. The Service Call still requires the appropriate classification, priority, status handling and Service Tasks. Where warranty work requires different service commitments, the applicable Call Type and SLA configuration must reflect those requirements.
Chargeability and invoicing
Warranty can change the Project Categories, Line Properties and chargeability of Service Task transactions. Covered labor or materials may therefore be processed differently from chargeable work. The applicable Project Integration determines how these transactions are posted and whether they are eligible for customer invoicing.
Financial reporting
Warranty costs must remain identifiable even when they are not invoiced to the customer. Appropriate Project Categories and Cockpit Categories allow the service organization to distinguish warranty expenses from regular chargeable service work.
Related documentation
See Service Objects for warranty information, Service Calls for warranty-related processing, Setup & Configuration for warranty and Project Integration settings, and Invoicing & Financial Integration for transaction processing.
Business scenario
A customer has a Service Contract that includes specific services, coverage conditions and response commitments. When service is requested, the organization must determine which rights apply and whether additional charges are permitted.
Contract determination
The Service Object and relevant date determine whether an active Service Contract applies. The contract identifies the covered objects and contains the applicable Service Level Definition, which establishes the available Call Types, default Call Type, Coverage Types and Project Integration.
Coverage and service execution
Coverage Types describe the services included in the agreement, while the SLD determines how those conditions are applied to Service Calls. Service Tasks continue to record the actual work performed, regardless of whether the customer is charged separately for the activity.
Commercial treatment
Contract coverage can result in different financial outcomes, including work included in a periodic contract fee, chargeable additional work or settlement against a prepaid amount. These outcomes depend on the Contract Type, SLD and Project Integration rather than on the Service Task alone.
Related documentation
See Service Contracts, Service Calls, Invoicing & Financial Integration and Setup & Configuration.
Business scenario
A service organization performs different types of work, including chargeable repairs, warranty services and contract-covered activities. Although technicians may register similar labor and materials, the financial outcome must reflect the applicable customer agreement.
Financial decision chain
The Call Type and applicable Service Level Definition determine which Project Integration is assigned to the Service Call. Project Integration establishes the default and permitted Project Categories, Line Properties and Invoice Status for each transaction type. This provides the connection between the service process and the financial treatment of the registered work.
Project Categories and Line Properties
Project Categories classify the nature of the transaction, while Line Properties and Invoice Status influence whether the transaction is chargeable. The same type of operational activity can therefore have a different invoicing outcome depending on the applicable Project Integration.
Price determination
Chargeability and price calculation are related but distinct decisions. Whether a transaction is invoiceable depends on its financial treatment, while the actual amount can be influenced by project pricing, contract-specific trade agreements, fixed service fees, Visit Tariffs or other configured pricing methods.
Financial validation
When an invoice amount is unexpected, trace the transaction from the Service Call through its SLD and Project Integration to the actual Project Category, Line Property and Invoice Status. Review the applicable price source separately. This approach helps distinguish an incorrect price from an incorrect chargeability decision.
Related documentation
See Service Calls, Service Contracts, Invoicing & Financial Integration and Setup & Configuration.
Business scenario
A service organization needs to record technicians' actual working time while charging customers according to a different commercial model. This may involve fixed service fees, rounded labor quantities or revenue-based charges instead of direct hour invoicing.
Hours via Revenue
Hours via Revenue provides a mechanism for converting registered labor into Revenue transactions for invoicing. The configuration relates Hour Categories to Revenue Categories and can apply specific rounding or rate rules. This separates the original labor registration from the transaction used to represent the customer charge.
Hours as Items
Hours as Items provides another conversion mechanism in which working time is represented through item-based transactions according to configured rules. The appropriate method depends on the intended commercial and financial treatment.
Financial considerations
Alternative labor billing must be designed together with Project Integration, Project Categories and Line Properties. Both the original labor registration and the resulting invoiceable transaction must be reviewed to prevent incorrect or duplicate charges.
Related documentation
See Invoicing & Financial Integration and Setup & Configuration. A separate functional whitepaper should provide detailed examples of Hours via Revenue, including transaction flow, rounding, posting and invoice results.
Business scenario
A service organization is responsible for maintaining equipment at agreed intervals or according to equipment usage. Maintenance activities must be forecasted, planned, executed and recorded without requiring the customer to report a malfunction.
Maintenance definition
Service Schedules define the maintenance activities and their timing. Frequency-Based Maintenance uses recurring calendar patterns, while Interval-Based Maintenance follows defined intervals or lifecycle milestones. Dynamic frequency scheduling can adjust future visits according to actual execution, and meter-driven scheduling can take equipment usage into account.
Contract integration
When maintenance is included in a Service Contract, Visit Schedules connect the maintenance requirements with the covered Service Objects. The forecast generates planned visits that can subsequently be converted into Service Calls and Service Tasks.
Execution and financial processing
The Event Code determines the maintenance work package, while the Service Task records the actual execution. The applicable contract coverage and Project Integration determine whether the maintenance activity is included in the agreement or results in additional customer charges.
Related documentation
See Preventive & Planned Maintenance, Service Contracts, Service Tasks & Execution and Planning & Scheduling.
Business scenario
A customer sends equipment to a workshop for diagnosis or repair. Unlike field service, the equipment is physically received, processed and returned, requiring coordination between service administration and inventory movements.
Service registration
The process begins with identifying the Service Object and creating a Service Call and repair-related Service Task. A workshop repair Event Code provides the required work package and initiates the associated repair-item movement.
Workshop processing
The repair item represents the customer equipment during its movement through the workshop warehouse. Diagnosis, quotation, repair execution and return handling take place within the Repair Centre process, while Service Tasks record the performed work and financial transactions.
Contract and warranty considerations
Workshop repairs may be covered by warranty or an existing Service Contract. These conditions affect the chargeability of labor, replacement parts and other transactions but do not replace the physical receipt and return process.
Related documentation
See Repair Centre for the functional introduction and the separate Repair Centre product documentation for workshop configuration and detailed repair scenarios.
Business scenario
A customer requests a service quotation before authorizing work, or additional work is discovered during an existing service activity. The service organization must obtain approval before proceeding with the proposed charges.
Standalone quotation
A Service Quotation can be created independently of an operational Service Call, including for prospects. The proposed work and transaction lines are priced, generated and submitted for approval. Once accepted, the quotation can be promoted into a new Service Call and Service Task.
Additional work
When additional work is identified during an existing service process, a quotation can be prepared and, after approval, transferred to an additional Service Task under the existing Service Call. This maintains the relationship between the original service request and the newly authorized work.
Related documentation
See Service Quotations, Service Calls and Service Tasks & Execution.
Business scenario
Service Tasks must be assigned to suitable resources while considering availability, required capabilities, service commitments and material readiness. The planner needs to coordinate the work without losing the relationship with the originating Service Call.
Planning requirements
Service Tasks provide the expected duration, Resource Requirements and operational context. The planner uses this information to select an appropriate resource and schedule the work. SLA deadlines, service locations and material availability can influence the planning decision.
Scheduling and dispatch
The graphical Planning & Scheduling functionality supports resource allocation and capacity reservations. Once scheduled, the Service Task can be executed by the assigned resource. Where Mobile Field Service is used, technicians can access and register their assigned work through the mobile application.
Related documentation
See Planning & Scheduling for the Service Management context and the separate Graphical Planning & Scheduling documentation for the shared planning functionality.
Business scenario
After completing service work, the organization must ensure that all activities have been registered, the correct costs and revenue have been posted and the customer receives an accurate invoice.
Operational completion
The technician registers the actual labor, materials, travel and Service Operations against the Service Task. Once the work has been completed and realized, the associated project transactions provide the financial record of the service activity.
Financial processing
The Service Call combines the transactions generated by its Service Tasks. The applicable Project Integration determines the financial treatment, while contract coverage, warranty and pricing rules influence which amounts are charged to the customer.
Invoicing and verification
Eligible transactions are collected through a project invoice proposal. Before posting, the user should verify the Service Call status, realized transactions, Project Categories, Line Properties, Invoice Status and expected invoice totals.
Related documentation
See Service Tasks & Execution, Invoicing & Financial Integration and Reporting & Support.